Is it better to throw it normally

if we call "throw;" instead "return;" exception will be bubbled in awaiter task , i.e. StopProcessingTasks->DeinitBuffersAsync and break them.
This can be done, but I think there is no point in causing a failure with Exception when closing the port.
... or I didn't understand, please explain

Throw the exception outward and catch it at the final call site, so that the stack trace is not hidden.

When physically disconnected, both tasks (_receiveTask, _sendTask) may fail with exceptions.
When attempting to close a port, an exception will be thrown in StopProcessingTasks, which will prevent the port from being closed. Port must be "closable" and release the resource in any case, even if some errors occur.

I did it: Default closing or Disposing the port will still ignore errors and free the port.
Closing a port with parameters (List? errors) allows you to get the entire stack trace and close the port. 30f2281

It is not recommended to integrate logging internally. Instead, exceptions can be thrown outward to preserve the stack trace, and handled by the user at the final call site.

In most cases, I needed logging when debugging, but Debug.WriteLine is very slow(Console.WriteLine much faster), which led to delays, GC and the buffer quickly overflowed.
Which option do you prefer?

1. We can remove logging and replace it with Debug.WriteLine where possible now
2. replace to DI Microsoft.Extensions.Logging.

ok :-)
I had time to think and I did it - logging removed 5f1cb60

A lot of stack trace information is being hidden in the code, which is quite problematic.

resolved : 30f2281

For most hardware, simultaneous write and read operations are not supported. Communication is typically request–response based, where the next request can only be sent after a reply is received. As a result, using a queue does not bring much benefit and instead makes the code more complex.

1. "Most equipment", but not all. All UART converters are asynchronous.
2. I tested, without dedicated tasks and queues, the processing speed drops significantly.
3. In Windows/Linux there is buffering, the driver does this there, in our case no one did this.
   for example, when working with ch340 or FTDI without such an implementation, the user will have to launch and maintain the reading thread themselves so as not to lose data.
   Not everyone has enough experience to understand how to implement this correctly, perhaps for this reason there is still no public working version and many are faced with data loss. UPDATE: readqueue already in master branch.
   My implementation ReadAsync WriteAsync - hi-perfomance, easy to use, do not require knowledge of threads, features of Android etc.

Neither Socket nor SerialPort has built-in queue processing; they only provide read and write functionality. Data queuing should be implemented as an extension of the communication library rather than being built in.

it's not the case, linux and windows simplify access to the UART by hiding the hardware implementation, queues and buffering, and it works conveniently.
Do you want to reject PR or do you want to move the buffering to a separate extension wrapper class?
Extension will require a lot of my time to develop, testing and coordinate the requirements with you.

Whether processing the received data directly is better than first enqueueing the data and then dequeuing it again for processing.

I tested: the task with UsbDeviceConnection.RequestWaitAsync should work as quickly as possible and mainly deal with waiting. If we start processing data directly in the same task, the data will begin to be delayed, the OS will quickly fill the buffers and the data will “begin to be lost”.
Second important note: a single android lock is used to enqueue and dequeue the linux buffer (in android line 115 ). This means that if we try to receive and send data from multiple threads, there will be a lot of blocking operations on that mutex.

Adding a try-catch block here is completely unnecessary. Any exception thrown after await will automatically propagate upward, and the stack trace will be preserved.

If we don't catch this exceptions, it will stop closing and propagate to Dispose - all will be broken.
Closing the port must occur without fail; it cannot be broken by exceptions.